alert definition: resource-condition: webServer, avg callTime(someurl) > 500ms or resource-condition: appServerJVM, freeMemory < 100MB or resource-condition: datasource, availableConnections < 5
Group alert definitions today do not have any interaction with the back-end alerting engine. They exist solely to create alert definitions on the members of the group, which then have their own resource-level semantics.
True group alerting would formally extend the concept of processing alerts to the group-level. Group alerting would create a new type of alert condition that is only relevant to a group.
Whereas on a resource I might say:
"alert me if this resource goes down"
In a group I would say:
"alert me if at least 2 (of 8) of my JBossAS servers in this cluster are down"
Another way of phrasing it might be:
"alert me if the group's availability drops below 75%"
Alert definitions today must be linked to a single related object - either a resource (regular alert definition), a group (group alert definition), or a type (alert template). We should redesign this such that the object is related to the alert condition instead of the alert definition. In this way, alert definitions become much more dynamic objects like so:
alert definition: resource-condition: webServer, avg callTime(someurl) > 500ms or resource-condition: appServerJVM, freeMemory < 100MB or resource-condition: datasource, availableConnections < 5
We can take this concept one step further and allow each of the conditions to be related to either a resource or a group:
alert definition: group-condition: webServerCluster, avg callTime(someurl) > 500ms or group-condition: appServerJVMAutoCluster, freeMemory < 100MB or resource-condition: databaseForCluster, (physicalMemory+virtualMemory) > 4GB